Skip to content

Conversation

@natarelli22
Copy link

Description
As explained on #322, MediaManager currently only matches torrents that represent full seasons or season packs.
As a result, valid episode-based releases — commonly returned by indexers such as EZTV — are filtered out during scoring and never considered for download.

Initial changes to the season parsing logic allow these torrents to be discovered.
However, additional changes are required beyond season parsing to properly support single-episode imports.

This PR is intended as a work-in-progress / RFC to discuss the required changes and align on the correct approach before completing the implementation.

Things planned to do
[X] Update Web UI to better display episode-level details
[ ] Update TV show import logic to handle single episode files, instead of assuming full season files (to avoid integrity errors when episodes are missing)
[ ] Create episode file tables to store episode-level data, similar to season files
[ ] Implement fetching and downloading logic for single-episode torrents

Notes / current limitations
At the moment, the database and import logic assume one file per season per quality, which works for season packs but not for episode-based releases.

These changes are intentionally not completed yet and are part of the discussion this PR aims to start.

Request for feedback
This represents a significant change in how TV content is handled in MediaManager.
Before proceeding further, feedback from @maxdorninger on the overall direction and next steps would be greatly appreciated.

Once aligned, the remaining tasks can be implemented incrementally.

@natarelli22
Copy link
Author

Results from the first commit (UI changes only)
image
image

On clicking on season row:
image

Context menu (three dots):
image
image

@maxdorninger
Copy link
Owner

Hi @natarelli22, thanks for working on this :)

Your plan looks good.

One thing I'd like to discuss is how exactly EpisodeFiles and SeasonFiles will be handled.

My idea would be that a SeasonFile will be composed of many EpisodeFiles. A SeasonFile must not contain more than 1 EpisodeFile of a specific Episode eg. S01E01. Whether an episode is imported or not would be stored in the EpisodeFile. Also the torrent associated with the episode would be stored in the EpisodeFile. But The FilePathSuffix would be stored in the SeasonFile.

This would mean when adding a torrent containing an entire season, a SeasonFile and all the EpisodeFiles will be created in the db. When adding a torrent with only one Episode, the user would have to choose to either add this one to an existing SeasonFile or create a new SeasonFile.

But as I am writing this, I realize that the SeasonFiles wouldn't be of much use then anyways since all they would do is store the FilePathSuffix and group EpisodeFiles by the FilePathSuffix. So I guess SeasonFiles could just be removed entirely since they don't really have a point when EpisodeFiles exist.

@natarelli22
Copy link
Author

Hi @maxdorninger, thanks for the detailed feedback — that aligns very well with the direction I was exploring.

As discussed, EpisodeFiles were introduced and, in my tests, they behave similarly to SeasonFile, but at the episode level.

I tested the following scenarios successfully: Full season packs, Mixed scenarios (partial season packs + single episodes) and Seasons composed only of single-episode torrents.

In all cases, episodes were imported correctly.
The season imported status logic was also refactored to be episode-aware, so a season is marked as fully imported only once all its episodes are imported, which matches the expected behavior.

At this stage, functions related to SeasonFile were not fully removed. A more detailed review is still needed to ensure EpisodeFile fully covers all existing use cases.
However, since only EpisodeFile entries are currently created during downloads, those SeasonFile-related functions should effectively be unused.

Functions related to Season Requests were intentionally left untouched for now. I planned to revisit them after approval of the current approach, once we are aligned on the data model.

I’m very open to adjusting this further based on your feedback, especially regarding whether SeasonFile should be fully removed or retained in some form.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants